There are three important concepts in object-oriented programming: encapsulation, inheritance, and polymorphism. Encapsulation refers to how implementation details are hidden by an abstraction called an "object." An object is said to encapsulate data and operations on that data. An object-oriented software system is made up of objects interacting with one another. They interact by sending "messages" to each other. An object implements its response to a message in a "method." Objects are unaware of each other's implementations; they only know the messages other objects respond to. Encapsulation controls complexity by partitioning the software system into small, well-defined pieces, and it makes it easy to change part of the system without affecting other parts.
Objects send messages as a result of receiving them. The "call stack" for an object-oriented program records the current chain of communication from object to object. After the first object on (the top of) the call stack sends a message to the second object, the first object waits for the method on the second object (which implements the message) to finish executing. After the second object on the call stack sends a message to the third object, the second object waits for completion of the corresponding method, etc. The last object on the (bottom of the) call stack is the one for which a method is being executed currently. The first object on the call stack is the "caller" of the second object on the call stack. The second object is the first's "callee." Similarly, the second object on the call stack is the caller of the third object, and the third is the callee of the second, and so forth.
Inheritance refers to taxonomic relationships between objects. An object belongs to and is defined by a "class." A class defines the set of messages an object can respond to, and it defines the data and methods that implement those responses. An object is said to be an "instance" of a class. A class can have arbitrarily many instances.
Inheritance lets classes be defined in terms of other classes. A class that inherits from another class is called a "subclass" of the other class (which is called the "parent class" or "superclass"). The subclass responds to the same messages as its parent, and it may respond to additional messages as well. The subclass "inherits" its implementation from its parent, though it may choose to reimplement some methods and/or add more data. Inheritance lets programmers define new classes easily as incremental refinements of existing ones. It also enables polymorphism.
Polymorphism refers to the substitutability of related objects. Objects are "related" if they have the same "type," and in most object-oriented languages that means they are instances of the same class, or they have a common parent class through inheritance. Objects that are related through inheritance may be treated uniformly, that is, without regard to their specific type. For example, a Graphic class that defines an abstraction for graphical objects may define a Draw method. The Graphic class might have subclasses Rectangle and Circle that reimplement the Draw method to draw a rectangle and circle, respectively. Polymorphism allows Rectangle and Circle instances to be treated uniformly as Graphic objects; that is, all one needs to know to tell an object to draw itself is that the object is an instance of a Graphic subclass. Whether the object is an instance of Rectangle or Circle is immaterial; one can send it the Draw message without knowing its exact type (e.g., Rectangle or Circle).
Polymorphism lets programmers write general code that can be customized later without change. Suppose we have code that draws pictures by sending Draw messages to a set of Graphic instances. We can pass it Rectangle and Circle objects, and it will tell them to draw themselves. Later we can define a new subclass of Graphic, say, Polygon, implementing its Draw method appropriately. Because Polygon is a subclass of Graphic, we can pass instances of Polygon to our picture-drawing code, and it will draw polygons in our picture--with no modification whatsoever.
Object-oriented programs often use thousands of objects, organized by tens or hundreds of classes. Often it's hard to understand how these programs work just by examining their code, since the code describes only the static aspects of the program (i.e., the classes). Understanding the dynamic aspects of the program requires a depiction of the program at execution time. Animated graphics are a way to depict an object-oriented program's execution.
U.S. Pat. No. 4,885,717 to Beck discloses a graphical presentation depicting individual objects on the display sending messages to each other. Objects appear as graphical nodes, and messages are shown as directed lines between the nodes. Once drawn, objects stay in fixed positions for the duration of the program's execution. No semantics are associated with placement of nodes.
Another well-known visual metaphor is the "interaction diagram," which also depicts messages to classes or objects over time. Typically, a message is shown as a labeled directed line that points to a perpendicular line denoting a class or object. Distance along the class or object line corresponds to time. Lines denoting messages are parallel to each other and are ordered to reflect the order in which the messages were sent Lines denoting classes or objects appear parallel to each other and perpendicular to the message lines. The advantage this metaphor has over Beck's approach is that repeated messages sent to the same or nearby objects do not interfere with each other, since time is given a physical dimension.